Implementering av Cross-Origin Säkerhet: Bästa praxis för JavaScript-kommunikation

I dagens sammanlänkade webb behöver JavaScript-applikationer ofta interagera med resurser från olika ursprung (domäner, protokoll eller portar). Denna interaktion styrs av webbläsarens Same-Origin Policy, en avgörande säkerhetsmekanism utformad för att förhindra skadliga skript från att komma åt känslig data över domängränser. Men legitim kommunikation mellan olika ursprung är ofta nödvändig. Det är här Cross-Origin Resource Sharing (CORS) kommer in i bilden. Denna artikel ger en omfattande översikt över CORS, dess implementering och bästa praxis för säker kommunikation mellan olika ursprung i JavaScript.

Förståelse för Same-Origin Policy

Same-Origin Policy (SOP) är ett grundläggande säkerhetskoncept i webbläsare. Den begränsar skript som körs på ett ursprung från att komma åt resurser från ett annat ursprung. Ett ursprung definieras av kombinationen av protokoll (t.ex. HTTP eller HTTPS), domännamn (t.ex. example.com) och portnummer (t.ex. 80 eller 443). Två URL:er har samma ursprung endast om alla tre komponenterna matchar exakt.

Till exempel:

• http://www.example.com och http://www.example.com/path: Samma ursprung
• http://www.example.com och https://www.example.com: Annat ursprung (annat protokoll)
• http://www.example.com och http://subdomain.example.com: Annat ursprung (annan domän)
• http://www.example.com:80 och http://www.example.com:8080: Annat ursprung (annan port)

SOP är ett kritiskt försvar mot Cross-Site Scripting (XSS)-attacker, där skadliga skript som injiceras på en webbplats kan stjäla användardata eller utföra obehöriga åtgärder på uppdrag av användaren.

Vad är Cross-Origin Resource Sharing (CORS)?

CORS är en mekanism som använder HTTP-headers för att låta servrar indikera vilka ursprung (domäner, scheman eller portar) som tillåts komma åt deras resurser. Det lättar i huvudsak på Same-Origin Policy för specifika förfrågningar mellan olika ursprung, vilket möjliggör legitim kommunikation samtidigt som det skyddar mot skadliga attacker.

CORS fungerar genom att lägga till nya HTTP-headers som specificerar tillåtna ursprung och de metoder (t.ex. GET, POST, PUT, DELETE) som är tillåtna för förfrågningar mellan olika ursprung. När en webbläsare gör en förfrågan mellan olika ursprung, skickar den en Origin-header med förfrågan. Servern svarar med en Access-Control-Allow-Origin-header som specificerar det eller de tillåtna ursprungen. Om ursprunget för förfrågan matchar värdet i Access-Control-Allow-Origin-headern (eller om värdet är *), tillåter webbläsaren JavaScript-koden att komma åt svaret.

Hur CORS fungerar: En detaljerad förklaring

CORS-processen involverar vanligtvis två typer av förfrågningar:

1. Enkla förfrågningar: Dessa är förfrågningar som uppfyller specifika kriterier. Om en förfrågan uppfyller dessa villkor skickar webbläsaren förfrågan direkt.
2. Preflight-förfrågningar: Dessa är mer komplexa förfrågningar som kräver att webbläsaren först skickar en "preflight" OPTIONS-förfrågan till servern för att avgöra om den faktiska förfrågan är säker att skicka.

1. Enkla förfrågningar

En förfrågan anses vara "enkel" om den uppfyller alla följande villkor:

• Metoden är GET, HEAD eller POST.
• Om metoden är POST, är Content-Type-headern en av följande:
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• Inga anpassade headers är satta.

Exempel på en enkel förfrågan:

GET /resource HTTP/1.1
Origin: http://www.example.com

Exempel på ett serversvar som tillåter ursprunget:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Some data"
}

Om Access-Control-Allow-Origin-headern finns och dess värde matchar förfrågans ursprung eller är satt till *, tillåter webbläsaren skriptet att komma åt svarsdatan. Annars blockerar webbläsaren åtkomst till svaret, och ett felmeddelande visas i konsolen.

2. Preflight-förfrågningar

En förfrågan anses vara "preflighted" om den inte uppfyller kriterierna för en enkel förfrågan. Detta inträffar vanligtvis när förfrågan använder en annan HTTP-metod (t.ex. PUT, DELETE), sätter anpassade headers eller använder en Content-Type annan än de tillåtna värdena.

Innan den faktiska förfrågan skickas, skickar webbläsaren först en OPTIONS-förfrågan till servern. Denna "preflight"-förfrågan inkluderar följande headers:

• Origin: Ursprunget för den anropande sidan.
• Access-Control-Request-Method: HTTP-metoden som kommer att användas i den faktiska förfrågan (t.ex. PUT, DELETE).
• Access-Control-Request-Headers: En kommaseparerad lista över de anpassade headers som kommer att skickas i den faktiska förfrågan.

Exempel på en preflight-förfrågan:

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

Servern måste svara på OPTIONS-förfrågan med följande headers:

• Access-Control-Allow-Origin: Ursprunget som tillåts göra förfrågan (eller * för att tillåta alla ursprung).
• Access-Control-Allow-Methods: En kommaseparerad lista över HTTP-metoder som är tillåtna för förfrågningar mellan olika ursprung (t.ex. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: En kommaseparerad lista över de anpassade headers som tillåts skickas i förfrågan.
• Access-Control-Max-Age: Antalet sekunder som preflight-svaret kan cachas av webbläsaren.

Exempel på ett serversvar på en preflight-förfrågan:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

Om serverns svar på preflight-förfrågan indikerar att den faktiska förfrågan är tillåten, kommer webbläsaren sedan att skicka den faktiska förfrågan. Annars kommer webbläsaren att blockera förfrågan och visa ett felmeddelande.

Implementera CORS på serversidan

CORS implementeras primärt på serversidan genom att sätta lämpliga HTTP-headers i svaret. De specifika implementeringsdetaljerna varierar beroende på vilken server-side-teknik som används.

Exempel med Node.js och Express:

const express = require('express');
const cors = require('cors');
const app = express();

// Aktivera CORS för alla ursprung
app.use(cors());

// Alternativt, konfigurera CORS för specifika ursprung
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: 'Detta är en CORS-aktiverad resurs' });
});

app.listen(3000, () => {
  console.log('Servern lyssnar på port 3000');
});

cors-middlewaret förenklar processen att sätta CORS-headers i Express. Du kan aktivera CORS för alla ursprung med cors() eller konfigurera det för specifika ursprung med cors(corsOptions).

Exempel med Python och Flask:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "Detta är en CORS-aktiverad resurs"}

if __name__ == '__main__':
    app.run(debug=True)

flask_cors-tillägget erbjuder ett enkelt sätt att aktivera CORS i Flask-applikationer. Du kan aktivera CORS för alla ursprung genom att skicka app till CORS(). Konfiguration för specifika ursprung är också möjlig.

Exempel med Java och Spring Boot:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

I Spring Boot kan du konfigurera CORS med en WebMvcConfigurer. Detta ger finkornig kontroll över tillåtna ursprung, metoder, headers och andra CORS-inställningar.

Sätta CORS-headers direkt (Generiskt exempel)

Om du inte använder något ramverk kan du sätta headers direkt i din server-side-kod (t.ex. PHP, Ruby on Rails, etc.):

Bästa praxis för CORS

För att säkerställa säker och effektiv kommunikation mellan olika ursprung, följ dessa bästa praxis:

1. Undvik att använda Access-Control-Allow-Origin: * i produktion: Att tillåta alla ursprung att komma åt dina resurser kan vara en säkerhetsrisk. Specificera istället exakt vilka ursprung som är tillåtna.
2. Använd HTTPS: Använd alltid HTTPS för både det anropande och det serverande ursprunget för att skydda data under överföring.
3. Validera indata: Validera och sanera alltid data som tas emot från förfrågningar mellan olika ursprung för att förhindra injektionsattacker.
4. Implementera korrekt autentisering och auktorisering: Se till att endast auktoriserade användare kan komma åt känsliga resurser.
5. Cacha preflight-svar: Använd Access-Control-Max-Age för att cacha preflight-svar och minska antalet OPTIONS-förfrågningar.
6. Överväg att använda autentiseringsuppgifter (credentials): Om ditt API kräver autentisering med cookies eller HTTP-autentisering, måste du sätta Access-Control-Allow-Credentials-headern till true på servern och credentials-alternativet till 'include' i din JavaScript-kod (t.ex. när du använder fetch eller XMLHttpRequest). Var extremt försiktig när du använder detta alternativ, eftersom det kan introducera säkerhetssårbarheter om det inte hanteras korrekt. När Access-Control-Allow-Credentials är satt till true, kan Access-Control-Allow-Origin inte sättas till "*". Du måste explicit specificera tillåtet/tillåtna ursprung.
7. Granska och uppdatera CORS-konfigurationen regelbundet: När din applikation utvecklas, granska och uppdatera regelbundet din CORS-konfiguration för att säkerställa att den förblir säker och uppfyller dina behov.
8. Förstå konsekvenserna av olika CORS-konfigurationer: Var medveten om säkerhetskonsekvenserna av olika CORS-konfigurationer och välj den konfiguration som är lämplig för din applikation.
9. Testa din CORS-implementering: Testa din CORS-implementering noggrant för att säkerställa att den fungerar som förväntat och att den inte introducerar några säkerhetssårbarheter. Använd webbläsarens utvecklarverktyg för att inspektera nätverksförfrågningar och svar, och använd automatiserade testverktyg för att verifiera CORS-beteendet.

Exempel: Använda Fetch API med CORS

Här är ett exempel på hur man använder fetch-API:et för att göra en förfrågan mellan olika ursprung:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // Talar om för webbläsaren att detta är en CORS-förfrågan
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('Nätverkssvaret var inte ok');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('Det uppstod ett problem med fetch-operationen:', error);
});

Alternativet mode: 'cors' talar om för webbläsaren att detta är en CORS-förfrågan. Om servern inte tillåter ursprunget kommer webbläsaren att blockera åtkomst till svaret, och ett fel kommer att kastas.

Om du använder autentiseringsuppgifter (t.ex. cookies) måste du sätta credentials-alternativet till 'include':

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // Inkludera cookies i förfrågan
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS och JSONP

JSON with Padding (JSONP) är en äldre teknik för att kringgå Same-Origin Policy. Den fungerar genom att dynamiskt skapa en <script>-tagg som laddar data från en annan domän. Även om JSONP kan vara användbart i vissa situationer, har det betydande säkerhetsbegränsningar och bör undvikas när det är möjligt. CORS är den föredragna lösningen för kommunikation mellan olika ursprung eftersom den erbjuder en säkrare och mer flexibel mekanism.

Viktiga skillnader mellan CORS och JSONP:

• Säkerhet: CORS är säkrare än JSONP eftersom det tillåter servern att kontrollera vilka ursprung som får komma åt dess resurser. JSONP ger ingen ursprungskontroll.
• HTTP-metoder: CORS stöder alla HTTP-metoder (t.ex. GET, POST, PUT, DELETE), medan JSONP endast stöder GET-förfrågningar.
• Felhantering: CORS erbjuder bättre felhantering än JSONP. När en CORS-förfrågan misslyckas ger webbläsaren detaljerade felmeddelanden. JSONP:s felhantering är begränsad till att upptäcka om skriptet laddades framgångsrikt.

Felsökning av CORS-problem

CORS-problem kan vara frustrerande att felsöka. Här är några vanliga felsökningstips:

• Kontrollera webbläsarkonsolen: Webbläsarkonsolen ger vanligtvis detaljerade felmeddelanden om CORS-problem.
• Inspektera nätverksförfrågningar: Använd webbläsarens utvecklarverktyg för att inspektera HTTP-headers för både förfrågan och svar. Verifiera att Origin- och Access-Control-Allow-Origin-headers är korrekt inställda.
• Verifiera server-side-konfigurationen: Dubbelkolla din server-side CORS-konfiguration för att säkerställa att den tillåter rätt ursprung, metoder och headers.
• Rensa webbläsarens cache: Ibland kan cachade preflight-svar orsaka CORS-problem. Prova att rensa din webbläsares cache eller använd ett privat surfläge.
• Använd en CORS-proxy: I vissa fall kan du behöva använda en CORS-proxy för att kringgå CORS-restriktioner. Var dock medveten om att användning av en CORS-proxy kan medföra säkerhetsrisker.
• Leta efter felkonfigurationer: Leta efter vanliga felkonfigurationer som en saknad Access-Control-Allow-Origin-header, felaktiga värden för Access-Control-Allow-Methods eller Access-Control-Allow-Headers, eller en felaktig Origin-header i förfrågan.

Slutsats

Cross-Origin Resource Sharing (CORS) är en essentiell mekanism för att möjliggöra säker kommunikation mellan olika ursprung i JavaScript-applikationer. Genom att förstå Same-Origin Policy, CORS-arbetsflödet och de olika involverade HTTP-headers kan utvecklare implementera CORS effektivt för att skydda sina applikationer från säkerhetssårbarheter samtidigt som de tillåter legitima förfrågningar mellan olika ursprung. Att följa bästa praxis för CORS-konfiguration och regelbundet granska din implementering är avgörande för att upprätthålla en säker och robust webbapplikation.

Denna omfattande guide ger en solid grund för att förstå och implementera CORS. Kom ihåg att konsultera den officiella dokumentationen och resurserna för din specifika server-side-teknik för att säkerställa att du implementerar CORS korrekt och säkert.

Ytterligare resurser

• MDN Web Docs: Cross-Origin Resource Sharing (CORS)
• W3C: Cross-Origin Resource Sharing (CORS)
• PortSwigger Web Security Academy: CORS